Solicited opinion: the output comparison of an erlang module looks good enough to me.

I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using aws-erlang but perhaps one can offer a minified version of the library without types in that case.

Good job! 😄

Solicited opinion: the output comparison of an erlang module looks good enough to me.

I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using aws-erlang but perhaps one can offer a minified version of the library without types in that case.

Good job! 😄

I tried to generate the edocs (using rebar3 ex_doc) for the generated types but apparently edoc explodes trying to parse the binaries <<"BinaryThingy">> as if it's an XML-tag so I gotta figure out how to deal with that 👍 But then yes, the idea would be to have good docs on the types and hence aid developers in having more information on what's expected as input into the APIs 👍

Thank you for the comment 🙇‍♂️

Updated generated code examples that are in the description.

Main changes pushed are:

• Generate common errors in order to unify types and reduce noise
  • Thanks Jesper (colleague) for that tip ❤️
• Ensure that for Elixir, typedoc examples are considered code blocks
  • Thanks @LostKobrakai for that tip! ❤️

Reception from colleagues, @LostKobrakai and @philss have been good 👍
I haven't seen anyone yelling "NOOOOO!" on Elixir/Erlang Slack so I'll polish this up over the coming days so we can get this into a mergeable shape 👍 I'm quite happy with how the output looks, just need to polish up some of the cr*ppy code I wrote in this branch 😄

• Get rid of code duplication in .eex modules
• Move some of this parameter types stuff that currently lives in rest_service.ex to types.ex or a similar module
• Fix rest_service:join_parameter_types to not have as much nesting
• Shapes could probably be moved to one module and hence reduce the clauses in types.ex
• collect_shapes/2 is the same across both post and rest similar with is_input/1
• Are the things living in Util really living in the right place?

Declined in favor of #109 due to wrong branch naming.